Unification of CC Pedagogical Software Frameworks

Software development at CC has historically been funded directly from projects and under current funding opportunities this likely to continue. While functionality has been re-used across projects we will be more effective by integrating core pedagogical infrastructure upon which each project innovates.

Our general goal is creation, research, and dissemination of highly interactive learner materials in which powerful exploration, modeling, and construction tools are combined with implicit and explicit embedded assessment. In general most of our work has been in Java and we expect that to continue however as much as practical our core frameworks should designed for heterogeneous language environments. This is most important at the data persistence and transport layers.

In order to innovate more quickly and to provide more powerful environments for research, testing, authoring, and delivery of highly-interactive learning materials to individual learners as well as learner workgroups we have been specifying and building a core architectural framework for this work.

Our current work is based on a synthesis of the Scalable Architecture for Interactive Learning (SAIL) we have been working on with teams at U.C. Berkeley and the University of Toronto and the OTrunk framework developed at CC.

SAIL is a framework that supports authoring, delivers units, and manages pedagogically meaningful learner-data persistence in a network environment so that student work and activity versions can be stored and retrieved over the Internet. SAIL represents the product of over a decade of prior research into technology-enhanced student learning.

OTrunk is a Java framework developed at Concord Consortium that supports the creation and modification of rich Java component-based interactive content and the persisting of both author and learner state of this content. OTrunk uses otml, an extensible declarative xml-based language for both declarative layout and composition of content as well as for object state persistence (both learner and authored data).

In order to support our research using these technologies Concord has developed the Sail Data Service (SDS). The SDS is a Ruby on Rails web application that handles:

• Learner data persistence for SAIL applications
• Delivery of dynamically-generated Java Webstart jnlp applications customized for the learner.
• Providing detailed researcher reports about student interaction with SAIL curriculum.

Building on these frameworks CC has developed the Do It Yourself (DIY) Portal and Authoring technology to support simple template-based authoring of highly interactive Java-based learner materials in which powerful exploration, modeling, and construction tools are combined with implicit and explicit embedded assessment.. The DIY technology is built using the Ruby on Rails web framework.

What works as of August 2007

These are the essential elements that synthesizing these core frameworks gives us now:

1. A document architecture which combines rich components with more traditional static forms of learning materials such as formatted text, graphics, and animations. Embeddable components developed both at CC and elsewhere currently include:
   • Computational models with visual representations developed at CC. These include among others Molecular Workbench, as well as dynamics and biological models developed using Pedagogica.
   • Computational models with visual representations developed elsewhere. These include Java models developed at the PhET Project at the University of Colorado including the: Circuit Construction Kit, Wave Interference Model, Sound Model, Faraday Model, and Discharge Lamps Models.
   • Algebra Interactives developed at CC for the Seeing Math Project: Linear Transformer, Piecewise Linear Grapher, Qualitative Grapher, Function Analyzer, Quadratic Transformer.
   • Graphs for displaying both real-time and saved data.
   • Sensor collection components for collecting and graphing real-time data from sensors as well as analysing previously-collected data.
   • Drawing tools which can range from a simple bitmapped painting, to object drawing, to concept mappping.
   • Mathematical tools which allow visual exploration of algebra concepts.
   • Models written
   • Models written in general purpose modeling languages such as NetLogo.
   • Assessments ranging from multiple-choice to open-response text input.
   • Components which can render web content ranging from html, css, to flash and quicktime. While browsers are very capable at this task there are many times in which web content may need to be delivered in a more contstrained environment which does not necessarily allow browsing to other sites.
2. Pedagogically-aware and network-enabled persistence of learner data.
   Whenever a learner uses our materials the application should know who they are and logging, report, or state data should be both delivered and saved for them over a network. These data are also used for:
   • Collection and reporting of learner data both in the raw form for processing by researchers and other programs as well as higher level repiorts on the web or in exchange forms such as a spreadsheet document.
3. Scripting of the visibility, sequence, presentation, and attributes of both the static and rich component elements of our materials. The presentation and operation of the material elements can be extensively scripted at a programming level while simpler forms of scripting are made available to an author using the WYSIWYG environment.
4. Reliable deployment to learner computing systems. For Java jnlp applications this means integrating jar differencing and compression to minimize the network bandwidth and startup time.

Current development efforts:

1. Developing a Swing based browser widget using JavaXPCOM.
   This will allow the embedding of anything that can be displayed in a Firefox browser to be used in a Swing-based Java application. This includes content rendered by Firefox plugins including Flash. In addition the scripting layer interconnecting embedded objects like Flash with other objects in the browser's DOM will also be accessible to Java. This is our medium-term strategy for a framework that can combine the best of what Java can offer with the best of what is available in a browser. We expect to have a 1.0 release within four months. The code will be available under any of these three licenses: GPL, LGPL, and MPL.
2. Continue and deepen integration of pedagogically-significant external Java components and applications with OTrunk.
   Initially the data structures of the authoring and learning states of newly integrated components are usually opaque to OTrunk however there are advantages to modifying a component so that it's state can be saved in canonical OTrunk form (as opposed to saving in OTrunk as an opaque blob). These advantages include being able to declaratively refer to attributes in the instantiation of one Otrunk component in a different OTrunk. For example it is easy in OTrunk to have one graph in which a learner makes a prediction and another later on which uses the data from that prediction as an overlay for a graph into which data from a sensor is to be collected. Additionally programmatic customization of an activity is much easier to accomplish with a declarative language like OTrunk. This is very important for the UDL project.
3. Extend the concept of OTrunk overlays to better support integrating the Author, Learner, and Teacher layers of an activity.
4. Extend and adapt SAIL and the SDS to support persistence at the Author, Learner, and Teacher layers.

Child pages

(sorted with the most recently updated first)